Increasingly, the Internet and other packet-based networks are being employed to provide telephony services ranging from a simple voice call between two parties to complex video conferencing between multiple geographically distant parties.
In a typical packet-based telephony session, a party at one endpoint (a calling telephone) picks up a handset (or otherwise causes the calling telephone to go “off-hook”) and enters a destination number for another endpoint (a called telephone). The off-hook condition of the calling telephone is sensed by a local media gateway that is connected to a packet-based data network. The entered destination number is passed over the data network from the local media gateway to a call server (which may also be called a connection manager) that supports the local media gateway. The local media gateway is effectively a “dumb slave” device under control of the call server. After consulting a table that associates destination numbers with data network addresses, the call server communicates over the data network with a remote media gateway associated with the called telephone and instructs the remote media gateway to cause the called telephone to ring. If the remote media gateway reports back to the call server success in causing the called telephone to ring, the call server instructs the local media gateway to play a ring tone on the calling telephone. The call server subsequently sends signaling to the data network to set up a call path (generically, a media path) between the local media gateway and the remote media gateway to carry bi-directional data traffic between the calling telephone and the called telephone.
If the called telephone is answered, the call path through the data network (established by call server signaling) may be activated. Once the call path has been activated, communication between either of the media gateways and the call server is generally not required until the call is complete and each of the telephones is returned to an “on-hook” condition. Upon the completion of a call, the call server receives an indication of the completion from each of the media gateways. As the call server has a record of the time of the beginning of the call and the end of the call, a complete record of the call may then be saved. Such a record of the call may also include an indication of the Quality of Service provided as well as other parameters related to the call path. Subsequently, the call server sends signaling to the data network to tear down the call path.
Data networking equipment for packet-based telephony can be expensive, not to mention time consuming to maintain. As such, packet-based telephony service providers fill a role by providing packet-based telephony to individuals or enterprises. These service providers typically bill their customers on a per-call basis and, therefore, it is important to the service providers that an accurate record of each call be maintained.
To build a reliable packet-based telephony network, it is desirable to include a backup call server. The backup call server may be used when an active call server fails or when network failure causes the active call server to be unreachable by its supported media gateways at the end of a call, which is when the indication of completion of a call is typically sent from a media gateway to the call server supporting the media gateway.
In some present architectures for telephony over packet networks, when a media gateway cannot communicate with its active call server, control of the media gateway may be switched over to the backup call server. Any calls in progress before the switchover can remain active after the switchover. However, at the end of a call whose control has been switched, the backup call server may not have a record of the beginning the call and therefore may not be able to provide an accurate record of the call for accounting and billing. For service providers that generate revenue on a per call basis, such lost, or inaccurate, records can result in lost revenue.
In a typical solution to this problem, the active call server passes information to the backup call server, typically using a proprietary communications protocol, thus keeping the backup call server updated with information about active calls. However, the performance requirements on the active call server are significant, as much of the communication between the active call server and each media gateway must be repeated to the backup call server. As well, there is a need, in this solution, to maintain a reliable link from the active call server to the backup call server and refresh lost information should the backup call server briefly disconnect from the active call server. It is generally necessary in this solution that the version of call server software at both the active and backup call servers be equivalent to allow for proper inter-working. This also means that the timing of upgrades to the software may be complex.